Exchange Server 2010 : Planning for Anti-Spam (part 2)

4. Connection Filtering

Connection filtering inspects the IP address of the remote server that is trying to send the message to determine what action to take on an inbound message. If a specific server is found on the IP Allow list or on the list of an IP Allow list provider, the message is not scanned anymore but directly marked as not spam. Similar to the IP Allow list, an IP Block list also exists that consists of servers that are not allowed to send messages because they have been identified as spam senders. The following sections discuss IP Allow lists and IP Block lists as well as list providers.

4.1. IP Allow List

An IP Allow list is a static list of trusted IP addresses manually created and managed by the Exchange server administrator. IP Allow list inspection is the first in the execution chain of Connection Filtering. You can include trusted IP addresses in the IP Allow list, such as the IP addresses of SMTP servers at your partner organizations. If a connection request comes from an IP address on the IP Allow list, the server does not apply additional anti-spam filtering and accepts the message.

To configure an IP Allow list and either add a single IP address or an IP range to the list, you need to use the Add-IPAllowListEntry cmdlet.

4.2. IP Allow List Providers

IP Allow List Providers is a feature that allows you to take advantage of dynamic safe lists of IP addresses maintained by a third-party providers. To use these lists you need to configure an external provider that maintains a safe list of SMTP servers instead of defining it yourself. In essence, configuring IP Allow List Providers is very similar to configuring IP Block List Providers and both use the same technology to retrieve the verdict about the connecting IP address from the providers.

4.3. IP Block List

Similar to the IP Allow list, the IP Block list feature examines connecting IP addresses against the static local list of IPs manually maintained by the Exchange administrator. In many cases administrators include on the list IP addresses of SMTP servers known to send spam or other MTAs from which they do not want to receive e-mail. If the Connection Filtering agent finds the IP address of the sending server on the local IP Block list, the server rejects the message without allowing the connecting party to initiate SMTP mail transaction.

You can configure a single IP address or IP address ranges that are blocked, and you can also define an expiration time on each entry so that you can block an IP address temporarily.

If you enable Sender Reputation filtering, it will add the IP addresses that exceed defined Sender Reputation Level (SRL) to the IP Block list for the configured amount of time.

4.4. IP Block List Providers

IP Block List Providers, or real-time block lists (RBLs), contain a list of known IP addresses of SMTP servers that are considered risky for sending spam. Because spammers use a variety of techniques to send spam and fool the receiving servers into accepting it, identifying their IP addresses and verifying them for "spamminess" is a very useful way to prevent spam from entering Exchange organizations.

If enabled, the Agent will send a DNS query to a manually configured IP Block List Provider and if the response from the provider indicates that the connecting IP is on the list, the Connection Filtering agent will reject mail transaction after the RCPT TO: command.

The rejection logic has been designed to accommodate various exceptions or cases when one or more recipients in the Exchange organization might need to receive all e-mail sent from the block-listed IP because of various business needs. (For example, spam analysts might need to investigate a newly unfolding spam attack or the Exchange administrator might set up a honey pot account to collect mail for forensics.) Whatever the reason, you can configure specific e-mail addresses as exceptions so that they will receive all messages, even if the connecting IP is on the RBL.

There are multiple real-time IP Block List Providers who maintain and service RBLs. You need to account for many factors when deciding which RBL provider to use. Some of the most important factors are the ability of the provider to service requests for removal of mistakenly or maliciously block-listed IP addresses, supportability channels, and responsiveness to customer issues. Of course, you also need to account for the cost of using the provider's services. Most RBL providers do not charge fees if the number of DNS queries is relatively low—for example it does not exceed 250,000 queries per day. However, if the number of queries exceeds this threshold, the provider won't service requests originating from high-volume IP addresses and instead will ask you to obtain their list via a zone file transfer, and the provider will charge a fee for that. Many RBL providers are available on the market, including the following:

• cbl.abuseat.org

• dnsbl.sorbs.net

• spamhaus.org

• bl.spamcop.net

A very useful cmdlet to determine whether your IP Block List Providers are working correctly is the Test-IPBlockListProvider cmdlet. You can either test a single RBL or you can test an IP address using all your configured RBLs, as shown in Figure 3.

Please be aware that the more RBLs you configure, the longer the verification process will take. Thus it is recommended not to exceed two or three RBLs. One positive match is sufficient to block the sender.

Another advantage of using Forefront Protection 2010 for Exchange Server is that it relieves administrators of the work required to configure, maintain, and administer IP block lists. The product comes with a feature called Forefront DNSBL, which is an aggregation of multiple feeds from many RBL providers, including SpamHaus and internal Microsoft feeds such as the block list from the Forefront Online Protection for Exchange team. The aggregated feeds are combined into a single database and positioned on a Microsoft-owned DNS infrastructure. The feature is administration- and maintenance-free, meaning the Exchange administrator has nothing to configure or monitor/maintain.

5. Sender Filtering

The Sender filter compares the sender on the MAIL FROM: SMTP command to a list of senders or sender domains that are prohibited from sending messages to the organization. After the sender is filtered, there are two possible actions: reject the message or stamp the message and deliver it. The blocked sender information is included as one of the criteria when content filtering processes the message.

6. Recipient Filtering

The Recipient filter compares the message recipients on the RCPT TO: SMTP command to an administrator-defined Recipient Block list. If a match is found, the message is not accepted for the recipient specified on the Recipient Block list but will be delivered to other recipients who are not on the list. If multiple recipients are listed on the message and some are not on the Recipient Block list, further processing is done on the message. The Recipient filter also compares recipients on inbound messages to the local recipient directory to determine whether the message is addressed to valid recipients. When a message is not addressed to valid recipients, such a message can be safely rejected during SMTP transaction.

Enabling the Block Messages Sent To Recipients That Don't Exist In The Directory option might disclose your Active Directory recipient information to malicious users executing a Directory Harvesting Attack (DHA) against your organization. To circumvent such attacks Exchange server enables you to configure tarpit intervals (tarpits are delays between the command coming from a remote computer and when Exchange server replies confirming or rejecting valid recipients). This is a highly effective technique that renders DHAs against Exchange organizations not feasible. The tarpit option is configurable and the default value is 5 seconds (which means Exchange server will delay response to every invalid recipient command for 5 seconds).

7. Sender ID Filtering

The Sender ID framework is an industry standard that allows companies to verify the IP addresses for incoming messages to ensure that they come from authorized servers. The Sender ID Framework provides highly effective protection against e-mail domain spoofing and phishing schemes. However, Sender ID is not used by many large corporations.

To take an advantage of the Sender ID Framework, domain owners must register all the IP addresses for all the SMTP servers that send e-mail from their SMTP domain with special DNS records. When using Sender ID filtering, the recipient messaging server initiates a DNS lookup to verify that the connecting IP is allowed to deliver messages on behalf of that domain. If the domain information does not contain the connecting server's IP address, the messages can be filtered out. Figure 4 illustrates the Sender ID filtering process.

As displayed in the figure, Sender ID filtering follows these steps:

If you're interested in additional information about the Sender Policy Framework (SPF), you can access it at http://www.openspf.org/.

7.1. Sender ID and Sender Policy Framework (SPF) records

To take an advantage of the Sender ID Framework and protect their own name brand and reputation, each e-mail sender must create a Sender ID or SPF record and add it to their domain's DNS records. The record is a single text (TXT) record in the DNS database that identifies each domain's e-mail servers. Sender ID records can use several formats, including the SPF record format examples as listed in Table 1.

Litware.com. IN TXT "v=spf1 mx -all"

Litware.com IN TXT "v=spf1 ip4:10.10.0.20 -all"

Litware.com IN TXT "v=spf1 a -all"

Litware.com IN TXT "v=spf1 mx mx:berlin-et01
.emea.litware.com mx:berlin-et02.emea
.litware.com -all"

Additionally, you should be aware of the different configuration options you have using the all part of the SPF record in DNS. The options are listed in Table 2.

Microsoft provides the Sender ID Framework SPF Record Wizard to verify your organization's Sender ID and SPF records in DNS. It is available at http://www.microsoft.com/mscorp/safety/content/technologies/senderid/wizard/. The wizard allows you to create a Sender ID record that meets your organization's exact needs.

7.2. Configuring Sender ID Filtering

Sender ID filtering is enabled by default with the option to stamp the header with Sender ID verdict and continue message processing. Other possible options are Reject and Delete.

It is very important to understand that the filter will implement Reject or Delete actions if and only if the Sender ID validation on the connecting IP failed. This means that the connecting IP cannot legitimately send mail on behalf of the domain it claims to be from, which is pretty much a spoofing attempt. In all other cases (for example, in the event of a transient DNS error, or if Sender ID records are misconfigured, do not exist, or are temporarily not available) the filter will not reject or delete message. It will stamp the verdict onto the message and pass it on to the next filtering technology.

Sender ID is not a mandatory requirement in Internet SMTP messaging; however, it is the technology that will help protect your company's name brand and prevent spoofing attacks. But the evidence is that many large companies don't use Sender ID yet. For example, at the time of this writing, neither HP nor GE nor Siemens publish Sender ID records in DNS; whereas IBM, Microsoft, and Google do.

In many cases Sender ID is your best and only defense when Zero Day attacks unfold, so it is recommended that you create and maintain Sender ID records and implement Sender ID filtering in Reject mode. Sender ID, when correctly implemented, is very safe to use and helps to improve your reputation as a responsible, legitimate sender.